前言：Hermes 在這個系列裡是代寫工具，還是協助我理解與驗證的學習夥伴？

在 Day 1，我提到這個系列不是從零開發一個新的 App，而是回頭重讀大一時完成的 Android 專題－ RoomRush。

不過，既然這個系列會使用 Hermes Agent，就一定會遇到一個問題：我到底是在學習，還是在讓 AI 幫我完成工作？

平常使用 AI 時，很容易讓人產生一種「我好像懂了」的錯覺：它可以快速整理檔案、解釋程式碼、列出架構，甚至把一段原本很混亂的內容講得很有條理。

然而，如果我只是看過它的解釋，沒有自己回到程式碼確認，也不能用自己的話說明，那其實只是把「不懂」包裝成「看起來懂」。

所以在這個系列裡，我不想把 Hermes Agent 當成代寫內容的工具，我希望它更像是一個讀 code 的學習夥伴：幫我拆解問題、提醒我哪裡需要驗證、指出我可能看漏的地方，甚至在我以為自己懂了的時候，反過來檢查我的理解是否正確。

使用 AI 重新讀專案，最大的風險是什麼

使用 AI 來幫助我讀懂整份專案，聽起來固然很簡單、方便，但最大的風險是：我真的有理解嗎，還是我只是自以為自己懂了？

AI 雖然可以很快且很詳細的解釋程式碼，但如果我沒有經過認真的思考，那其實這對我說沒什麼價值，只是認為自己會了罷了。因此，我在讓 Hermes 幫助我讀懂專案時，事前來回溝通了很多細節，讓我可以消化學習內容，透過問答的方式，能更加深我對專案的印象。

一般 AI 和 AI Agent 的差別

在這個系列裡，我使用的是 Hermes Agent，而不是只把問題丟給一般 AI 聊天機器人。

對我來說，一般 AI 比較像是「問答工具」。
我貼上一段程式碼，問它這段在做什麼，它可以很快整理出一段說明。這很方便，但如果我只是看過它的回答，沒有自己回到程式碼確認，就很容易產生一種「我好像懂了」的錯覺。

AI Agent 比較不同的是，它可以協助我完成一整段工作流程。
例如：讀取實際檔案、整理檔案關係、追蹤資料流、檢查我自己的回答，甚至把每次理解整理成筆記或文章素材。

我自己會這樣比較：

這樣比較下來，我認為 Hermes Agent 可以更符合我對重讀專案的需求，

儘管如此，AI Agent 不是魔法。
它不是一定正確，也不能替我完成理解。如果我只是複製它整理好的內容，那它仍然會變成另一種代寫工具。

Hermes Agent 在這個系列中會做什麼

在這個系列裡，我會讓 Hermes Agent 協助我做幾件事：

1. 整理檔案之間的關係並拆解重點：例如在 RoomRush 中，它負責什麼、某個 Activity 對應哪個 layout、使用哪個 ViewModel、資料從哪裡來。
2. 設計問題來讓我回答，並逐題檢查我的理解和解釋有沒有錯誤：
   • 判斷：正確 / 部分正確 / 需要修正
   • 哪裡對
   • 哪裡不精確
   • 怎麼修正
3. 拆解程式碼：不是只翻譯每一行，而是說明這段程式在整個功能流程裡負責什麼。
4. 接回「資料流」或「畫面流程」：清楚了解每份檔案的傳遞和附屬關係。
5. 幫我找出當初專案可能忽略的問題：例如命名不一致、資料來源不清楚、錯誤處理不足、程式碼重複、功能耦合太高。
6. 最後，幫我整理成學習筆記：解析完所有的檔案之後，我會回顧相關檔案及筆記，以便整理成鐵人賽的文章。

Hermes Agent 不會替我做什麼

雖然我會使用 Hermes Agent，但有些事情我不希望完全交給它：

1. 不直接替我假裝理解：如果我不能用自己的話說出來，就不算真的看懂。
2. 不直接大改專案：這個系列的重點是讀懂與整理，不是每抓到一個技術債就重構整個 App。
3. 不直接相信它的解釋 AI 有可能講錯，也可能把看起來合理的推測說得很肯定：所以重要的地方，我還是要回到程式碼本身確認。
4. 不讓它把我的專題包裝得太完美：畢竟 RoomRush 是一個學生專題，它有努力完成的地方，也一定有技術債。這個系列要記錄的是我怎麼面對它，而不是把它寫成一個沒有缺點的作品。

我會如何驗證自己真的看懂

我的使用方式：不是問「幫我解釋」，而是問「請逼我確認」

我不希望自己只是問：

請幫我解釋這個檔案。

就讓 Hermes 產生整份檔案的解釋和用意，因為這樣會變成只是我被動接收答案。

我更希望使用這種問法：

• 請先根據這個檔案整理它的角色，然後問我問題，確認我是否真的理解它。
• 請檢查我對這段程式的理解有沒有錯，錯的地方請指出來。
• 請幫我追蹤這個畫面按下按鈕後，資料會經過哪些檔案。
• 請找出這個功能中最可能造成維護困難的地方，但先不要幫我改，先讓我理解問題。

透過這種方式，每當我詢問某個檔案時，Hermes Agent 就會有一個固定的工作流程來幫助我讀懂專案。

對我來說，AI Agent 的價值不在於它幫我省掉理解，而是它讓「理解」這件事變得有流程、有檢查點，也比較不容易只停在看答案。

接下來我會照什麼順序開始重讀 RoomRush

下一篇開始，我會正式進入 RoomRush 的程式碼。目前理解專案的順序是：

第一條主線：使用者查詢空教室流程

AndroidManifest.xml
→ MainActivity.kt
→ QueryResultActivity.kt
→ QueryResultViewModel.kt
→ EmptyRoomAdapter.kt
→ RoomDetailActivity.kt
→ RoomDetailViewModel.kt
→ 使用者查詢流程總結

這條線會幫我看懂使用者從打開 App、選大樓、查詢空教室，到點進教室詳細頁，中間經過哪些檔案。

第二條主線：資料來源與 Room Database

ClassroomSchedule.kt
→ ClassroomScheduleDao.kt
→ ClassroomScheduleRepository.kt
→ AppDatabase.kt
→ EmptyRoomFinderApp.kt
→ AppContainer.kt
→ 資料來源主線總結

這條線會幫我看懂課表資料從 CSV 進來後，如何變成 Room Database 裡的資料，又如何透過 DAO、Repository 提供給 ViewModel 使用。

第三條主線：管理者功能與資料維護

LoginActivity.kt
→ ManagerActivity.kt
→ LessonManageActivity.kt
→ LessonManageViewModel.kt
→ AllClassroomsActivity.kt
→ AllClassroomsAdapter.kt
→ ClassroomScheduleDetailActivity.kt
→ ClassroomChooseManageActivity.kt
→ ClassroomManageActivity.kt
→ 管理者功能總結

這條線會幫我看懂管理者如何登入後台、修改課表、新增或編輯教室資料，也會讓我檢查資料保存、安全性與可維護性上的技術債。

下一篇預告：我先問自己：這個 Android App 到底從哪裡開始？

我想先從 Android 專案最外層的入口開始看，也就是 AndroidManifest.xml。

它就像是 App 的目錄和登記元件及入口，裡面記錄了有哪些 Activity、哪個畫面是啟動入口，以及 App 需要哪些基本設定。

如果連入口都沒有看懂，後面直接跳進某個 Activity，其實很容易迷路。